汽车ECU标定的实现方式

我在阅读汽车常见芯片的data sheet时候，经常发现芯片有Emulation Device和Production Device两种类型。

以英飞凌TC3xx系列为例，ED的芯片主要应用场景如下：

再如瑞萨的RH850 P1x-C

我们发现，在ED片子里，均有对标定场景的覆盖。仔细阅读后，发现ED的片子在debug接口和ram、flash做了不同程度的扩展；而结合这几年的xcp开发经验，我并没有实际用到过ED的片子；因此结合现有资料想来聊聊ED、PD片子不同的标定方式，

这篇文章主要内容包括：

• 常见的xcp标定
• ETK技术
  
• VX1000高性能标定
• ASAM MCD-1 POD / ASAM MCD-1 XCP v1.5(Debug over XCP)

---

1.常见的XCP标定

最初做TC275的基于AUTOSAR XCP协议栈移植，采用的XCP on CAN(现在进化到CanFD和ETH居多)，常规是WP->RAM，RP->Flash的映射方式(在此感谢我的老大)，借用ETAS一张非常经典的描述XCP的图。

当上位机工具切换到WP时，可以通过download命令，修改RAM的标定常量，如下：

当切换到RP时，可以读取到Flash的原始值，不能修改标定量，标定界面会变为灰色。如下：

这里我们可以看到一个很神奇的事情，对于ECU来说，标定量仅存在一个地址(Map文件中定义)，且只有RAM的地址可以进行修改；所以我们在最初不知道overlay的情况下，都是在链接文件中做手脚，如下：

这种方式表示实际存储在Flash中，但加载运行是在RAM里；编译出来的map文件对应的地址就是RAM地址。

后来慢慢了解到tricore的overlay功能，那么就更简单了，在编译时根本不用再调整链接文件，只需要配置ovc寄存器，例如将PFlash 32K overlay到cpu0 DSPR 32K，那么上位机就可以直接使用Flash地址对齐进行标定，因为虽然download命令下发的是Flash地址，但通过cpu视角来看，实际访问的是ram地址。

目前OEM、供应商给的软件开发规范基本都是对xcp保留一路CAN。但以前遇到一个问题，当时使用的是标准CAN，对于测量周期，客户有一个需求，即要求DAQ周期为2ms，实际上在标准CAN的情况下，1ms最多可以发送标准CAN报文4帧，即一个DAQ周期最多8帧，如果选用ODT格式选用绝对地址，则总共可以发送有效数据7*8=56个bytes；这很明显对于电机类的测量是不友好的，甚至出现过因为DAQ一直把总线占着，导致系统效率降低的情况；因此xcp in CANFD/ETH慢慢普及了。

---

2.ETK技术

再后来，接触到了联电的客户，给我做了一个关于ETK的技术培训；先总结如下：

    ETK（Emulatortastkopf） 是一种内存模拟技术，它是 ECU 中的一块特殊用途的电路模块，提供基于并行通讯的应用（与上述xcp on can/eth的串行技术有区别）。ETK 通过直接同控制单元处理器的总线进行连接，从而提供高速数据通讯，ETK 可以单独替代控制器 ECU中的标定数据也可以同时替代控制器 ECU中的标定数据和程序（执行代码）。原理如下：

值得注意的是到这里，就出现了两种不同实现方式的标定技术，且这两种互不冲突，如下：

进一步的，我们来了解ETK里面到底有什么东西，这是一张带ETK的ECU内部结构图：

很明显，由于其自带RAM和Flash，且和ECU之间是通过并行访问，因此在标定过程中几乎不会消耗CPU资源。在实际开发中，如果开发阶段ETK 的角色既要管理 Data 部分，还可以管理Code部分，则需要将代码和数据全部下载到ETK，且只需要做一次；对于只管理 Data 部分的 ETK，ECU在执行过程中从 ETK 的 WP或 RP 中访问数据，从其自身的 Flash 中读取代码。值得注意，ETK在ECU掉电后自身也有供电的。

随着技术的进步和ASAM MCD-1 POD（后面聊）的诞生，ETK技术进一步进化，如下：

既然并行标定技术这么高效，为什么现在还是一个582或者591、592比较普遍呢？原因就是ETK加标定工具，太贵！一个581/2可能淘一淘小千，一个带ETK的ECU加标定工具，可以搞好多好多581了。

回到正题，这个ETK技术，再结合英飞凌、瑞萨等厂家的Emulation Device；我发现这是芯片厂不想你ETAS（Bosch dad）一家独大啊，干脆在芯片设计时就将这种技术考虑进芯片内部。

所以接下来，我们就要聊VX1000高性能标定。

---

3.VX1000高性能标定

VX1000的高性能标定实现是基于带POD的ECU，具体如下：

与ETK技术一样，采用了并行访问的方式，以实时核M7为例（红色线），如果要对M7上的应用程序进行参数标定，使用VX1000是非常容易实现的。

ECU端不需要集成xcp协议栈，ECU端只需要将debug口（NXP叫SWD，英飞凌叫DAP/JTAG）引出，与Vector针对芯片定制的POD(Plug on Device)连接，POD又与VX1000(Base Module)相连接。PC端与串行标定一样作为MC(测量/标定)master，Base Module里集成了XCP Slave协议栈，这意味着什么？Master发送的所有的关于XCP指令，都在VX1000里做出了解析，并根据ASAM MCD-1 POD协议转换成另一种数据帧通过POD->SWD，发送给ECU；M7(ECU)里虽然不集成XCP协议栈，但是根据POD协议，需要集成POD API、POD Service Software、Vendor Service Software等等。不用担心，Vector已经为我们做好了准备，如下：

当要做高性能标定测量时，需集成VX1000IF/Driver到ECU工程里；根据参考手册打开VX1000_Cfg.h中的各种宏。编译通过，刷ECU，开始测量标定。

至于如何做到高性能测量的呢？有这么一个图可以看到：

在高性能测试时，代码里已经没有以前串行标定时DAQ事件触发CanIf_Transmit这个动作了，只有memcpy动作，POD通过DMA的方式直接从OLDA Memory里去获取数据；这样既不会占据总线带宽，也不会消耗cpu过多资源，毕竟现在已经有memcpy按word方式copy的片子了。通过实际代码demo我们也可以看到：

而实际标定时，也是master发送download指令在slave完成解析，通过SWD直接进行修改。

---

4.ASAM MCD-1 POD / ASAM MCD-1 XCP v1.5(Debug over XCP)

做标定的最先遇到的肯定是ASAM MCD-1 XCP，对slave开发来说，其中的各种指令更是非常熟悉。但是标定工程师不一样，他们主要是对控制算法的调参，如果采用高性能标定的方式，debug被标定工具霸占了，ECU需要debug，那这又怎么办呢？因此在2017年ASAM又提出了debug over xcp的方式，劳特巴赫、isystem相继进行调试器上的优化，如下：

winIdea/Trace32是运行在PC上的XCP Master，它们不会直接向目标发送低级别的调试命令，而是将这些命令封装为XCP命令的形式，发送到POD上的XCP Slave以进行进一步处理。

这些玩法对于国内高端主机厂、tier1来说应该很常见，但对于以成本为导向的供应商、OEM来说，简直就是天书，以至于到目前，我还没接触过这种东西。并且debug over xcp的参与方目前仅有如下单位：

好好好好，这么玩是吧，看不惯AUTOSAR那批人，你们开始垄断调试了是吧，那既然你们参与了这个，跟这种调试手段相关的POD，想必你们也要掺和掺和；为此我又去看下ASAM MCA-1 POD的官方指定合作伙伴

ETAS\VECTOR哪里都有你们是吧。

哎，为什么我司还没有和他们合作呢？我也想进步呢。

5.小结

到这，我基本上掏空了。

现目前汽车软件开发，给我感觉就是技术迭代非常快，以至于我还没把CP autosar摸透，马上就有AP的需求挂过来；基础的TC3xx、S32K、U2A这些MCU片子功能还摸透，马上TC4xx、S32Z就又扑过来了。

时代在进步，我们也要跟上步伐呢。

---

---

参考文档：

1. https://etas.services/zh/products/etk_fetk_xetk_ecu_interfaces-details.php
2. https://www.asam.net/standards/detail/mcd-1-pod/wiki/
3. https://www.asam.net/standards/detail/mcd-1-xcp/wiki/

4. Technical Reference MICROSAR VX1000If

5. VX1000 - Getting started with TriCore DAP

6. https://www.isystem.com/products/winidea-xcp-master-debug-and-trace-over-xcp.html

7. https://www.lauterbach.com/products/software/debugging-via-xcp